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techniques for managing a system safety program and the technical methods 
recommended for use in developing a risk evaluation prog ram that is oriented 
to: 


a. The identification of hazards in aerospace hardware systems. 

b. The development of residual risk management information for the 
program manager that is based on the hazards identified. 

The methods and techniques described in this volume are in consonance with 
the requirements set forth in NHB 1700.1 (VI), Chapter 3. 
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be invoked in contracts. 
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Office, Code DY), Washington, D.C. 20546. 
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ORGANIZATION OF THE NASA SAFETY MANUAL 


OVERALL COVERAGE 

The NASA Safety Manual will be issued in several volumes, by major safety 
subject breakdowns. The following list shows the initial plan for publishing 
the individual volumes: 

Assigned 

Volume Title No. 


1 Basic Safety Requirements 1700. 1(V1) 

2 Reserved 

3 System Safety 1700. 1(V3) 


DOCUMENT REFERENCING 

Each volume is assigned its own identification number within the basic classi- 
fication code. The alpha-numeric suffix within a parenthesis identifies the 
volume of the manual; e.g., NHB 1700.1(V3): this number indicates that this 
is the third volume. 

When a volume is revised, the suffix identification will be changed to indicate 
the revision number such as NHB 1700.1(V3-A). 

In referencing or requesting any volume of the NASA Safety Manual, the com- 
plete, specific NHB number must be used. 


PARAGRAPH REFERENCING 

1« Within the NASA Safety Manual . The following shows the general paragraph 
numbering system applicable to all volumes: 

_3_ _3 01 la(l)(a) 

A A A A 

Volume 3 ] 

Chapter 3_ 

Paragraph 30 1 

Subparagraphs __ 

This system provides for referencing any paragraph or complete volume 
requirement in any other volume of the NASA Safety Manual without the need 
for identifying the NHB number and title. 

2. In Other NASA Documents . When it is necessary to reference any para- 
graph in any other NASA document, the specific NHB number and paragraph 
number must be used together as follows: "NHB 1700. 1(V1), par. 1103-la 
(l)(a)," or "paragraph 1 103-la(l)(a) of NHB 1700. 1(V1)." When it is neces- 
sary to reference any complete volume in any other NASA document, the 
specific NHB number (which also identifies the volume) must be used. 
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CHAPTER 1: MANAGEMENT TECHNIQUES 


3100 INTRODUCTION 

There is direct relationship between the degree of safety achieved in a 
NASA aerospace system and the management emphasis placed on the 
safety of the system being designed, manufactured, tested, and operated. 
This chapter of the safety manual describes the tasks that should be 
accomplished and the working relationships that should be established to 
formalize the system safety effort into a discipline, to the end that the 
program manager will have maximum visibility into the risks he is 
assuming. 

3101 PURPOSE AND SCOPE 

This chapter provides functional safety managers with an outline of the 
techniques that are useful in the planning, implementation, and admin- 
istration of a system safety program. The management techniques de- 
scribed are applicable to any size or type of NASA hardware develop- 
ment program and throughout the entire system life cycle. These 
methods should be implemented to the extent that the evolving 
system safety effort fully supports the unique needs of the hardware 
program. This Volume is intended to be evoluntionary in nature and 
therefore subject to continuous upgrading and change as new methods 
are developed and have been proven satisfactory for NASA application. 

3102 RISK EVALUATION 

1. The program manager of an aerospace system must assume certain 
risks that are attendant to the design, manufacture, test, and opera- 
tion of the hardware system to effectively accomplish the mission 
for which the system was developed. The acceptance of these risks 
should be based on thorough visibility as to the nature of hazards 
and risks that are in existence and the options and alternatives to 
the acceptance of the risks. 

2. The decision on whether to assume a risk is clearly a program 
management responsibility. This decision is no better than the 
quality of the risk data that serves as a basis for the decision. Ac- 
cordingly, the development of hazard and risk data should be as- 
signed as a responsbility to professionals whose training and 
orientation cause them to search out and find the hazards in the 
system before these hazards manifest themselves in terms of 
damaged or destroyed hardware. 

3103 SYSTEM SAFETY PROGRAM ELEMENTS 

1. Each functional system safety program has nine basic elements 
which include: 

a. Planning, 

b. Organization, 

c. Contracting, 
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d. Interface/Coordination, 

e. Criteria, 

f. Analysis, 

g. Reporting, 

h. Evaluation, 

i. Data Retention. 

2. Each of the above elements and the related activities are described 
in the ensuing paragraphs. All of these elements are oriented toward 
an overall approach to risk evaluation by: 

a. Identifying the hazards in the system. 

b. Determining corrective actions that may be implemented to either 
remove, or control, the hazard or to provide alternatives. 

c. Recommending corrective action or alternatives to the appro- 
priate management level for a decision to either resolve the 
hazard or assume the risk. 

d. Documenting those areas in which a decision has been made to 
assume the risk, including the rationale for the risk assumption, 

3. The detail with which each of the nine safety program elements set 
forth in subparagraph 1. is developed and implemented is dependent 
upon the complexity and mission of the hardware system being de- 
veloped. 

3104 PLANNING 

1. PRELIMINARY SAFETY TASKS 

It is anticipated that, in most cases, formal planning of the safety 
effort for support of the system feasibility studies would not be 
initiated. There are, however, several typical safety tasks that should 
be completed during these activities. These tasks then become the 
foundation for the planning of system safety efforts during the system 
definition, design, manufacture, test, and operation. These include: 

a. A review of pertinent historical safety data from similar systems. 

b. A continuing review of the gross hardware requirements and con- 
cepts, to maintain an understanding of the evolving system. 

c. A review of the proposed mission objectives. 

d. Completion of the planning for follow-on safety activities. 

e. The completion of preliminary hazard analyses to identify 
potentially hazardous systems and to develop initial safety re- 
quirements and criteria. 
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f # Participation in trade studies with the result of the preliminary 
hazard analyses identifying highly hazardous areas, with recom- 
mendations as to the alternatives. 

g. Identification of the requirement for special contractor safety 
studies that may be required during system definition or design. 

h. Estimation of gross resource requirements for the system safety 
program during the complete system life cycle. 

i. Preparation of an index document that identifies all pertinent 
safety data developed during the life cycle of the system, such as 
the results of analyses, the criteria and requirements imple- 
mented, the results of special studies and the applicable his- 
torical data. This index is updated at the conclusion of each major 
increment of the system development or as determined by pro- 
gram milestone dates. 

2. GOALS AND OBJECTIVES 

a. Any planning exercise requires that certain basic decisions be 
made. Safety goals and objectives should be established, and the 
type of system safety input that is to be furnished to the overall 
program should be determined prior to initiating the planning 
effort. Goals should be measurable in every case and should 
state what system safety would intend to accomplish as a result 
of having performed the various safety tasks. 

b. Once these safety goals and objectives have been established and 
agreed upon by appropriate program management level, the 
planner can begin to become familiar withboththe evolving hard- 
ware system and the environment within which the safety program 
is to be conducted. Having equated the safety goals to the needs 
of the system being developed, the planner considers all the 
alternative methods and analyses that can be used to meet these 
safety goals and objectives. The optimum methods are selected 
from these alternatives and the planning is begun. It should be 
noted that these goals must be structured such that safety tasks 
can be selected that will accomplish the goals and when the tasks 
have been completed the result of the effort will clearly demon- 
strate that the goals have been met. 

3. PLAN CONTENTS 

The Safety Plan should include: 

a. A description of the initial safety tasks initiated during the feasi- 
bility studies, system definition, design, manufacture, test or 
operation that are to be continued throughout the forseeable future 
of the system life cycle. 

b. Additional tasks that are to be initiated during ensuing program 
activities that evolve from the list of safety elements described 
in paragraph 3103. 
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c. The development of requirements for contractor safety effort. 

d. An estimate of numbers and types of personnel required for the 
safety effort. 

e. A description of the methods that will be used to perform these 
safety tasks, control the effort and accomplish the objectives. 

f. Scheduling the safety effort including milestone identification, 
program activities, phasing, and integration. 

g. Identification of the safety output that will result from the effort, 
the expected application of the output, with provisions for the 
documentation of specific results of the safety effort. 

A typical safety plan outline is shown as Figure 1. 

4. PLAN REVISIONS 

a. It should be noted that if the planned safety program is to have 
sufficient flexibility, the individual plan must be revised as re- 
quired to satisfy the changing needs of the program, although the 
plan should not be revised for the sake of change alone. Further, 
it can readily be seen that a plan may vary in size from one page 
in length to a detailed multi -page document, depending on the size, 
complexity and needs of the system. 

b. The planning tends to be an iterative process in that the plan is 
refined and expanded as milestones of the system development 
are accomplished. Emphases are realigned, nonproductive tasks 
are abandoned and new tasks developed as required to accomplish 
the safety goals. Analysis methods are evaluated against pro- 
gram needs and specific techniques are selected and implemented, 
as required to provide a sufficient depth of safety/risk evaluation 
visibility. 

3105 ORGANIZATION 

1. The organization of the functional system safety effort is developed 
to accomplish the tasks set forth in the safety plan. Safety may be 
part of the system engineering organization or part of a systems 
effectiveness organization, collocated with the reliability, quality or 
maintainability organizations. As a general rule, to maintain objec- 
tivity and the check and balance system, it is preferable that system 
safety not be part of the design engineering organization. 

2. The major safety tasks to be accomplished are broken down into 
subtasks and responsibilities assigned that will support accomplish- 
ment of the safety goals. The ongoing activities, together with the 
quantity and complexity of the safety tasks scheduled for completion, 
dictate the size and technical depth of the safety organization. For 
example, a safety organization may vary from only one man who 
spends part of his time accomplishing the safety tasks to an organi- 
zation of 20 or more people supported by an extensive contracted 
effort. Obviously good staffing practices should be followed, and the 
greatest possible technical professionalism developed. 
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CHECKLIST OF REQUIREMENTS FOR A SYSTEM SAFETY PLAN 


1.0 PURPOSE AND SCOPE 

2.0 APPLICABLE DOCUMENTS 

(Reference only documents cited in the plan text) 

3.0 SAFETY ORGANIZATION 

3.1 Relationship to total organization 

3.2 Organizational array 

3.3 Responsibilities 

3.4 Interfaces 

4.0 SAFETY TASKS TO BE COMPLETED 

4.1 Criteria development 

4.2 Analyses 

4.3 Design/program review participation 

4.4 Contractor/subcontractor requirements 

4.5 Reporting 

4.6 Documentation 

4.7 Planning 

4.8 Evaluations 

5.0 METHODS FOR ACCOMPLISHING SAFETY TASKS 

5.1 Criteria - development, documentation and monitoring 

5.2 Analysis technique 

5.3 Other program activities 

6.0 SCHEDULE FOR TASK COMPLETION 

(Keyed to major program milestones) 

Figure 1 
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3. Irrespective of the relative size of the safety organization, it should 
be placed in the reporting chain at a point which allows the risk 
evaluation output resulting from the safety effort to flow directly to 
the appropriate level of management in support of risk management 
decisions. 

3106 CONTRACTING 

1. TWO FORMS 

Contracting of a system safety effort may take one of two forms. The 
effort may be contracted in a separate contract, such as a special 
safety study during the early development, or may be part of the 
total system procurement package. In either case, unless the re- 
quirements being contracted are carefully prepared so that the con- 
tractor clearly understands what he is expected to accomplish, the 
contractor cannot provide the engineering and management services 
being sought. The fundamental elements of the two forms of pro- 
curement mentioned above are essentially the same and follow a 
well-defined procurement system (see NASA Procurement Regula- 
tion, Subpart 52 - SAFETY). 

2. THE REQUEST FOR PROPOSAL (RFP) 

The RFP must state in clear, concise terms: 

a. The scope of the effort. 

b. The specific tasks the contractor is expected to perform. 

c. The reporting requirements. 

d. The program milestones that must be met. 

e. That the contractor is expected to provide a system safety plan 
as part of his bid package, which is in consonance with para- 
graph 3104. This contractor plan should include a listing of the 
system safety tasks he plans to complete and include a descrip- 
tion of: 

(1) The methods he plans to use in accomplishing these tasks. 

(2) The output or product that will be produced by the safety 
effort. 

(3) The use that will be made of the safety output. 

(4) The organization that will be developed to complete the task. 

(5) The deliverables. 

(6) The reporting of safety problems, activities, and accomplish- 
ments. 

(7) The sub-tier schedule of activities leading to task completion 
in support of major program milestones. 
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3. PROPOSAL EVALUATIONS FOR SOURCE SELECTION 


The safety manager should participate in the proposal evaluation 
activities and rate each proposal on the basis of the contractor's 
demonstrated understanding of the RFP requirements reflected in 
his plan as well as the cost history and the history of the contrac- 
tor's past performance. 

4. THE STATEMENT OF WORK 

The evaluation of the proposal should also lead to the decision on the 
suitability of the contractor's system safety plan for use as a seg- 
ment of the overall statement of work. Normally a separate segment 
of the statement of work covering the system safety requirements, 
included in the contract schedule, is preferable to negotiation of the 
contractor's safety plan since the contractor's plan is his blueprint 
for meeting the requirements. This s egment of work may be based on 
the original RFP and the safety data submitted by the contractor as 
part of his bid package. 

3107 INTER FACE /COORDINATION 

1. GENERAL 

The effectiveness of the functional system safety effort is determined 
by the quality and quantity of the output and how that output is ap- 
plied. The development of the output is dependent upon the interfaces 
established, the currentness and quality of the data safety personnel 
have to work with, and the technical competence within the safety 
organization. 

2. INTERFACE ESTABLISHMEN T 

Working interfaces should be established at the earliest possible 
time in the system development and should be postured on the basis 
that system safety has a valuable service to provide the other organi- 
zations in the program. As each interface is established, the safety 
manager should strive to reach an understanding with his counter- 
parts as to: 

a. The type of data that is to be produced by each organization. 

b. The amount of this data that will be needed by safety personnel 
and a schedule for its availability. 

c. The use safety personnel will make of this data. 

d. The output of the safety effort including the format and availability 
schedule. 

e. The safety data or effort that may be required by the interfacing 
organizations . 

Typical interfaces and data flows are pictured in Figure 2, which 
shows the safety activity set apart on the left in order to better 
describe the data exchange. 
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SAFETY INTERFACES AND TYPICAL DATA FLOW 
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OPERATIONS PROCEDURES ANALYSES 






3. THE SAFETY -ENGINEERING INTERFACE 


The interface with engineering is especially important,, This working 
relationship should be developed during the early part of the system 
development and continued throughout the life cycle to the conclusion 
of the program. System safety personnel work closely with engineer- 
ing personnel in developing safety criteria, and, based on the safety 
analysis, recommend methods of reducing risks, coordinate on the 
design of safety devices and recommend hardware changes to remove 
or control hazards. Safety personnel provide close support and 
assistance to the engineering staff during design and program re- 
views, and, as the result of having performed a thorough technical 
safety effort, should be able to make a significant contribution dur- 
ing these reviews in terms of visibility into the risk assumption 
status . 

4. THE SAFETY-R & QA INTERFACE 


a. The system safety-reliability and quality interface is of particular 
interest because the two areas can provide effective support to 
each other when properly conducted. Much of the data developed 
by the reliability program finds use by the functional safety effort 
in the preparation of the Safety Analyses, and there are com- 
mon interests between the two programs in design review, failure 
reporting and human error areas. It is therefore important that 
the two areas coordinate closely with one another in program 
planning and execution to ensure that each provides appropriate 
support to the other and that duplication is eliminated, 

b. The safety effort should provide the quality assurance organiza- 
tion with inspection requirements for safety items and informa- 
tion on safety critical characteristics. A rapid flow communica- 
tion channel should be established and maintained to assure that 
the safety staff receives quick notification of safety discrepan- 
cies, parts failures and assembly errors. 

5. THE SAFETY -CONF IG URAT I ON MANAGEMENT INTERFACE 

The safety-configuration management interface should be estab- 
lished as soon as the design of the system is sufficiently well de- 
fined to be controlled by a configuration management activity. Safety 
personnel should review all changes for their potential impact on the 
safety of the system. Safety changes especially should be reviewed 
to determine that they do improve the safety and reduce the risk suf- 
ficiently to merit implementing the change. The safety organization 
also should participate in all proposal and committing change board 
activities when safety changes are being exercised. 

6. THE SAFETY -MANUFACTURING INTERFACE 

a. The system safety-industrial safety working relationship is 
established in the manufacturing, test and operations areas. The 
system safety-manufacturing relationship can best be charac- 
terized as advisory in nature, depending largely on the relative 
effectiveness of the industrial safety program. 
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b. The system safety organization should review the manufacturing 
planning of critical activities to assure that a fabrication or as- 
sembly process does not exist that can result in residual damage 
being incorporated into the system as part of the manufacturing 
process. 

c. Major reliance is also placed on the quality control activities 
during the manufacture of the system. Requirements for special 
inspection of safety critical items and activities should be in- 
cluded on the proper drawings. These safety items are then 
inspected by the quality people as part of their regular inspection 
and buy-off activities with failure and rejection reports providing 
a rich source of useful safety data. 

THE SAFETY-SYSTEMS TEST INTERFACE 

a. The system safety staff works closely with the test organization. 
Test procedures are reviewed to assure that hazardous tests are 
identified as such and that the procedures, prepared to operate 
the system under test, contain shutdown and backout capability 
as well as cautions and warning notes. 

b. Test systems are analyzed to assure that hazards have been fully 
considered and that the risks are minimized wherever possible. 
Safety representatives should occasionally witness the accom- 
plishment of hazardous testing to measure the validity of the 
safety input to the test procedures and to gain a better under- 
standing of the test activities. 

THE SAFETY -OPERATIONS INTERFACE 

a. The safety activities completed during operation of the system 
include staff support during system final assembly, checkout and 
validation, maintenance and operation. Hazardous tasks per- 
formed as part of the checkout and launch are identified as such, 
and the supporting contingency planning is reviewed thoroughly 
to assure that exposure is minimized and recovery is well 
organized and planned. 

b. Operating procedures are reviewed to assure that backout or 
shutdown provisions, warning and caution notes have been in- 
cluded. 

c. Special attention is devoted to system interfaces since hazards 
recognize neither contract nor mechanical boundaries. The safety 
staff can make a major contribution to the system integration ac- 
tivities as a result of having completed the normal safety tasks. 

d. The participation of safety personnel in system operations should 
be on an active basis, to measure the validity of the safety input 
to the operations procedures and to become more familiar with 
the operational program. 



9. SYSTEM SAFETY -PROGRAM MANAGEMENT INTERFACE 


a. The effectiveness of the system safety effort is measured in terms 
of the safety impact on the system from the standpoint of reduced 
risks. One of the principal avenues available to exert this in- 
fluence on the system is through the program manager’s deci- 
sions. Accordingly, the safety manager must establish an effec- 
tive interface with the program manager so that the program 
manager will understand what kind of an output can be expected 
from the system safety effort, when this output will be received, 
and how it will be useful to him. Next, safety personnel must 
mount a competent effort to produce a technically accurate output 
which is acceptable to both engineering and the program manager 
from a technical standpoint. 

b. The provision of this safety output, in the main, should be sched- 
uled to the major program decision points such as the Prelimi- 
nary Design Review (PDR), First Article Configurationlnspection 
(FACI), Design Certification Review (DCR), Flight Readiness 
Review (FRR) and any other special reviews. The safety output 
should be expressed as a total risk profile with sufficient sup- 
porting data to enable the program manager to decide whether to: 

(1) Assume the risks; 

(2) Change the hardware to reduce the risks; or 

(3) Revise the mission to reduce the exposure of the hardware 
and thereby reduce the risks, or by imposing constraints at 
control exposure to high risks. 

c. The safety manager should evaluate the output produced by the 
effort performed in the name of safety on a continuing basis to 
assure that it is useful, and that it is being used. This provides 
a valuable control function to delete nonessential tasks from the 
on-going safety activities, 

10. OTHER INTERFACES 

Where more than one field installation is involved in conducting the 
system development and operation, it is vital that interinstallation 
safety coordination meetings be held on a regularly scheduled basis 
and that communication channels be opened and encouraged for the 
expedited flow of safety data. This same type of safety data exchange 
system should be used in the case where more than one prime con- 
tractor is used by an individual field installation. 

3108 CRITERIA 

1. GENERAL 


The second method by which the system may be influenced in addi- 
tion to "through the decision process" (see paragraph 3107-9) is by 
means of the criteria and requirements specified for the design, 
development and operation of the system. Accordingly, special at- 
tention should be devoted to the system criteria development process. 
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2. DEVELOPMENT 


Criteria are originated from the results of the safety analyses and 
from the experience gained from other programs using similar sys- 
tems. The process is described in Figure 3 and is repetitive in 
nature to the extent that the criteria are evolved, imposed, and then 
evaluated for effectiveness on an iterative basis. Any requirement 
for which several waiver requests are received should be evaluated 
to determine the practicality of relaxing the requirement. Otherwise, 
waivers should be granted on a one-time-only basis. When a waiver 
is granted, the information should be documented as a matter of 
permanent record, with the reason or the justification for granting 
the deviation also recorded. It cannot be emphasized too strongly 
that each waiver may constitute an increase in the risk being as- 
sumed and each deviation must be evaluated on its own merits. In 
any case, waivers should be kept to a minimum. 

3. DOCUMENTATION 

All safety criteria and safety-related criteria should be recorded in 
one document which is maintained on an up-to-date basis to show 
how the requirements were developed and their current state of im- 
plementation. Also, the waiver system should be maintained on a 
very formal basis with each waiver an<t the circumstances of its 
issuance fully documented. 

3109 ANALYSIS 

1. System safety analyses are performed for the purpose of identifying 
hazards and establishing risk levels. Further examination will re- 
veal that in support of this concept, the analyses perform five basic 
functions : 

a. Provide the foundation for the development of safety criteria and 
requirements. 

b. Determine both whether and how the safety criteria and require- 
ments provided to engineering have been included in the design. 

c. Determine whether the safety criteria and requirements created 
for that design have provided adequate safety for the system. 

d. Provide part of the means for meeting pre-established safety 
goals. 

e. Provide a means of demonstrating that safety goals have been met. 

2. A very strong case can be made for the performance of safety analy- 
ses on any system, and all too often the decision on undertaking the 
effort is resolved down to a matter of economics. It is always neces- 
sary to be prudent in the allocation of resources for any effort. From 
the standpoint of safety analyses, economy should be based on the 
selection of the appropriate analysis techniques to be used, based on 
the requirements of the system, and the need for risk visibility. 
Economy should never be based on the performance of no safety 
analyses since the absence of analyses results in very little visibility 
for the program manager as to the actual risk assumption status. 
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SYSTEM SAFETY ACTIVITIES FUNCTIONAL FLOW 
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3110 REPORTING 


1. DEFINITION OF REQUIREMENTS 

The requirements for reporting of progress, hazards and activities 
should be defined in the various safety plans and/or contracts, 

2. GENERAL REPORTING 

General reporting covers progress of the effort, milestones attained, 
and significant accomplishments such as hazards identified and re- 
solved. This type of reporting generally flows in consonance with 
overall program reporting channels, 

3. PROGRAM REVIEWS 

Safety inputs to program reviews relative to the risks being assumed 
and the status of hazard resolution are usually construed as a type of 
reporting. This type of reporting is formalized around the individual 
program review format. 

4. SAFETY ANALYSES REPORT (SAR) 

The SAR, or an input to the SAR, should be prepared in support of 
each major engineering review and prior to beginning each mission. 
The requirements for the SAR are contained in paragraph 1310, and 
include such things as: 

a. Risk levels, in terms of risks being assumed. 

b. Rationale for the assumption of these risks and the alternative 
considered. 

c. Waivers to safety criteria that have been granted. 

d. System safety activities that are behind schedule and have not 
been completed. 

These SAR's serve as a total record of the risks assumed in order 
to complete each mission. 

3111 EVALUATION 

1. PURPOSE 

The evaluation of a system safety program is performed in order to 
determine that: 

a. The safety management system is properly structured. 

b. There is good access to both the system data and the proper 
management reporting level. 

c. The safety goals are being met and the planned tasks are being 
accomplished and are on schedule. 

d. There is an output resulting from the system safety effort. 

e. Effective use is being made of safety output. 
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2. METHOD 


a. The evaluation of a safety program is begun by planning the re- 
view, The system safety requirements that have been imposed on 
the organization are determined and a copy of the organization^ 
safety plan is obtained. In general, the most satisfactory approach 
is to measure the performance of the effort (what is being accom- 
plished) against the approved plan (what was intended to be ac- 
complished), Also an evaluation should be made as to whether the 
plan itself is current and still responsive to program needs. 

b. A checklist similar to the one shown in Figure 4 is a valuable 
tool for recording the relative acceptability of the various parts 
of the program. The numbers on the left of the checklist refer to 
chapters in NHB 1700. 1(V1). Special attention should be devoted 
to areas of effort receiving inadequate attention or the accom- 
plishment of nonproductive or redundant effort. 

c. The evaluation should include a discussion with the program 
manager to assess: 

(1) The quality of the output from the safety effort that reaches 
the program manager. 

(2) Whether this output arrives in time to be useful to the program 
manager. 

(3) How the program manager uses this safety input, 

(4) How the safety output can be improved and made more useful 
to the program manager. 

d. Upon completion of planning, the organization that is to be reviewed 
should be notified of the forthcoming evaluation and what is to be 
covered in the assessment sufficiently well in advance so that 
proper preparations and coordination can be completed. The 
evaluation begins with an initial briefing to the appropriate man- 
agement level that introduces the review team, covers the pur- 
pose of the review, identifies what is to be evaluated and assures 
a debriefing at the conclusion of the review, 

e. The review is completed according to plan and the debriefing is 
completed whenever possible with the same management people 
as participated in the entrance briefing. The purpose of this de- 
briefing is to come to an understanding of both the good things 
that were found and the areas requiring increased emphasis or 
improvement, 

f. The report of the evaluation is coordinated with the reviewed 
organization prior to publishing it, so that any discrepancies, 
misunderstandings, or inaccurcies can be resolved. 
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Organization Reviewed 


SAFETY EVALUATION CHECKLIST 
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3. SCHEDULING 


Reviews should be completed on a regularly scheduled basis, usually 
once a year. More frequent evaluations should be scheduled only 
when the review indicates a problem of major proportions that cannot 
be resolved with less emphasis than the forcing function of a major 
review. 

3112 DATA RETENTION 

1. As a result of having performed the safety activities described in 
this volume, extensive system safety data will have been developed, 
including : 

a. Criteria and requirements. 

b. Safety study reports. 

c. Other reports, progress/activity. 

d. Safety analysis reports. 

e. Analyses. 

f. Hazards reports. 

g. Accident reports, 

Z. These items are valuable safety data that may have application to 
other systems that are presently being developed, or will be devel- 
oped in the future, and as such these data should be documented for 
retention as they are prepared. 

3. An up-to-date index of these data should be maintained for each 
program that identifies this information by report number, title, 
date of final issue, location, and a pertinent summary abstract so 
that the data are readily available for use when needed. 
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CHAPTER 2: TECHNICAL METHODS 


3200 INTRODUCTION 

The formalization of the system safety activities in the hardware/ 
software development programs of NASA requires as a prerequisite 
the selection of certain technical methods that are generally accepted 
as the tools of that specific technology. It is recognized that only a cer- 
t a i n amount of basic data evolves as a hardware system is developed. 

These are the approved engineering drawings and specifications, together 

with hardware test results, and it is from these basic data that all an- 
cillary data are created. It therefore becomes a matter of major impor- 
tance as to how these basic data are used and in what manner the data 
are processed by the various supporting disciplines to accomplish their 
respective missions. This chapter contains a brief description of those 
methods that experience has proven to be most effective for use in 
processing the basic engineering data and applicable ancillary data into 
risk evaluation information. 

3201 PURPOSE AND SCOPE 

1. This chapter describes in broad terms the technical system safety 
methods that are available to a NASA program or system safety 
manager for use in accomplishing a risk evaluation program. The 
methods have been described in sufficient detail to provide under- 
standing of the techniques and permit an evaluation of the analysis 
results. This document does not provide detailed instructions on 
these methods sufficient to permit the use of this Handbook alone to 
perform these analyses. Hazard analysis reference publications and 
training courses are set forth in Appendixes Band C, respectively. 

2. The methods described herein are applicable to all NASA hardware 
systems. The analysis methods may be expanded, reduced or altered 
as required to suit the specific needs of any separate program, or 
initiated during any time in the system development, thus assuring 
maximum flexibility. Further, these methods are not restricted 
exclusively to system safety and should be considered for appli- 
cability to the industrial, public, and aviation safety activities. 


3. The reason for undertaking a program of safety analysis is to iden- 
tify the hazards in a system. Once identified, these hazards are 
evaluated, first in terms of the relative severity of the hazard, 
which is the effect the hazardous event would have on the system 
should the event occur and cause the system or an energy source to 
go out of control. Secondly, the hazards are evaluated in terms of 
the exposure of the total system or the time interval during which 
the hazardous event can affect the system, considering also the 
location of the hazard in the system. Thirdly, the hazard is evaluated 
in terms of the likelihood that this event will occur, and, if deter- 
mined quantitatively, may be expressed by means of probability 
calculations. 
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4. The safety analyses are then reapplied to systematically search for 
the alternatives to assuming excessively highrisks during the testing 
or operation of the system. 

3202 HAZARD ANALYSES 

1. The following analytical techniques are described in their logical 
order of application during the system development life cycle, as 
shown in Figure 5. The first method is the Preliminary Hazard 
Analysis, which is used in the early phases of the development to 
identify the energy sources being considered for use in the evolving 
system, together with the methods selected for the control of these 
energy sources. 

2. As the system becomes better defined and more detailed design data 
evolve, the Fault Hazard Analysis can be undertaken. This analysis 
addresses the system down to the piece-part level, if necessary, and 
should include such items as mechanical linkages, wiring and ducting 
which connect the critical system elements or components. 

3. The final analysis recommended for the more complex systems is 
the Logic Diagram Analysis which is used to identify critical failure 
paths. This analysis may be made quantitative using the Fault Tree 
Technique should the program manager require this amount of 
visibility. 

4. Finally, manufacturing, test and operating procedures should be re- 
viewed (Procedures Analysis) to assure that they are fully annotated 
with cautions and warning notes and that their use does not initiate 
any out- of- sequence events. 

3203 PRELIMINARY HAZARD ANALYSIS 

1. Usually the first analysis technique applied in a typical system 
development program is a preliminary hazard analysis based on 
descriptions of mission functions or events to be achieved. A pre- 
liminary analysis is performed by applying data obtained on pre- 
vious programs from systems analogous to those defined gener- 
ically from the descriptions of subsystems considered for use in 
accomplishing mission functions. The purpose of this analysis is 
to identify safety critical areas and the hazards involved in the 
mission(s) under consideration and provide management with risk 
visibility during either feasibility studies or system definition activ- 
ities. This preliminary analysis provides a comprehensive listing of 
hazards commensurate with the generic system(s) defined. The com- 
parative data utilized from analogous systems in previous programs 
reflect the results of potential hazards identified from analyses and 
experience with those hardware systems, with emphasis on all as- 
pects of these systems and their usage. 

2. The preliminary hazards analysis should include: 

a. A review of all pertinent safety data produced by other NASA 
systems to take advantage of previous safety experience. 
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SAFETY ANALYSIS - PROGRAM ACTIVITY RELATIONSHIP 



Figure 5 
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Procedures Analysis 
(Test Operations) 




b. A review of all pertinent data related to the evolving system as 
a means of learning the system. 

c. A listing of all energy sources such as: 

(1) Electrical 

(2) Mechanical 

(3) Chemical 

(4) Nuclear 

d. Determining the design features or procedures that have been 
developed to control the energy sources listed in subparagraph c. 

e. Identifying energy sources for which inadequate controls have 
been adopted, or high risk areas. 

f. Identifying safety requirements and criteria incorporated or 
needed to assure control of the energy sources and documenting 
them for future program application. 

g. Making recommendations to the program manager in cases where 
inadequate controls exist. 

h. Reiterating the process as frequently as required to support 
major program changes. 

i. The use of this information as applicable for an input into trade 
studies and program reviews. 

3. In performing a preliminary hazard analysis, a chronological listing 
of functions or events provides a basis for defining generic systems. 
An example listing of mission functions or events with generic sys- 
tems to perform those functions on an unmanned space vehicle is 
presented in Figure 6. 

4. The next step in the preliminary hazard analysis is to determine the 
hazards involved with each of the defined generic systems. The haz- 
ard determination is based on data and experience from previous 
programs. For brevity in this hazard analysis example, the listing 
of hazards for only one of the mission functions is presented. Un- 
desired events and their causes for the generic systems defined 
from a launch-boost function are presented in Figure 7 together with 
identified safety features and inadequate controls as a means of 
determining areas needing further consideration. 

3204 FAULT HAZARD ANALYSIS 

P This analysis technique is the second in the series, with increased 
complexity over the Preliminary Hazards Analysis. A more com- 
pletely defined system and greater system knowledge are required 
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UNMANNED MISSION FUNCTION LISTING EXAMPLE 


MISSION EVENTS 
LAUNCH- BOOST 

FAIRING SEPARATION 
ORBITAL INJECTION 

SOLAR PANEL DEPLOYMENT 
ATTITUDE POSITIONING 

ORBIT CORRECTION 

DATA ACQUISITION 

MID-COURSE CORRECTION 

STAR ACQUISITION 

DATA ACQUISITION AND 
TRANSMISSION 


GENERIC SYSTEMS 

Guidance, Fuel, Engines, Destruct 
Staging, Oxidizer, Flight Control, 
Electrical, Telemetry 

Separation, Electrical 

Engine Shutdown, Payload Separation, 
Electrical, Guidance 

Squib, Unfolding, Electrical 

Reaction Control, Electrical, Navi- 
gation 

Propulsion, Computer, Electrical, 
Navigation 

Antenna, Telemetry, Computer, Elec- 
trical 

Propulsion, Computer, Navigation, 
Electrical 

Navigation, Reaction Control, Com- 
puter, Electrical 

Sensing, Data Storage, Telemetry, 
Electrical 


Figure 6 
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EXAMPLE LISTING OF HAZARDS FROM PRELIMINARY ANALYSIS 
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for this analysis since the emphasis is oriented to the appropriate 
system element level, rather than toward a systems approach. The 
analysis provides greatly increased visibility from the standpoint of 
primary and secondary failures, as well as sequential failures, and 
may be performed either as an extension of the Failure Modes and 
Effects Analysis (FMEA) or independently from the FMEA. In the 
event that FMEA's have not been accomplished, a comparable set of 
data must be developed by the safety analyst before the Fault Hazard 
Analysis can be completed. 

Z. The data required for this analysis include up-to-date: 

a. Drawings, specifications and hardware (system) descriptions. 

b. Mission time lines (projected). 

c. Failure modes and effects analyses. 

d. Historical data including test results. 

3. The Fault Hazard Analysis (FHA) is used to define the effects of 
various subsystem component or piece-part failure modes, to evalu- 
ate these effects on system equipment or personnel, and to determine 
which subsystem effects should be further analyzed during subse- 
quent safety analysis. The FHA considers all these system elements 
in the subsystem and, therefore, all the interface effects resulting 
from internal failures. Analyzing at the appropriate system ele- 
ment level allows the identifiable hazards to be found, because, in 
the FHA, each hazardous event must terminate in a subsystem major 
component, 

4. The format shown in Figure 8, which is an extension of the normal 
FMEA, may be used in performing the Fault Hazard Analysis. The 
following subparagraphs provide information on the use of this format 
by reference to column heading: 

a. Component , Components are defined, at the discretion of the 
analyst, by their physical or functional significance to the 
subsystem or its design concept, or in accordance with 
NHB 5300. 4(1A), Reliability Program Provisions for Space System 
Contractors. The following guide for defining the major com- 
ponents is included to facilitate understanding of the types of 
natural separations to consider. It is not intended to be exhaustive. 

(1) Electronic Logic Circuits . Many components are made up from 
a small number of basic circuit designs which perform an 
identifiable purpose. These are used as building blocks for 
larger circuits designed to perform the required logic func- 
tions to the subsystem. To minimize the analysis required, 
the basic circuits can be defined as major components, and 
an analysis made of each logic function. 

(2) Mechanical Devices . Mechanical devices can be either a single 
part or an assembly of parts which perform one function. For 
a Fault Hazard Analysis, a major mechanical component can 
be defined as either of these. The use in the circuit will dictate 
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to what level of detail mechanical parts should be considered* 
Single parts which might be considered major components are: 
solid drive shafts, engine blocks, primary structure, etc. The 
majority of mechanical devices will be assemblies of many 
parts and it is more reasonable to treat the assemblies as 
major components. For example: relays, pumps, motors, 

mechanical safety devices, and other similar devices. This 
permits the majority of vendor supplied mechanical de- 
vices to be analyzed as major components, thus avoiding the 
requirement for vendors to provide Fault Hazard Analyses of 
their subsystems. 

(3) Electrical Systems . Major components can be basic compo- 
nents of a circuit or combinations of components (such as 
amplifiers, rectifiers, or regulators) used to perform one 
single function. The level of analysis should be based on the 
importance of the part as a functional element in the design. 

(4) Chemical Systems . In systems containing chemical compounds, 
the chemicals should be considered as major components if 
these compounds can cause failures of other components 
through chemical reaction or release of chemical energy. 
Examples of chemical components are: fuels, pressurants, 
coolants, and preservatives. 

(5) Safety D evices . Safety devices should always be considered 
major components since they are used primarily to protect 
against undesired events. 

(6) Wiring . Interconnecting wiring of major components may be 
considered a major component. Internal wiring can be con- 
sidered as a part of a major component . Physical characteris- 
tics of cables which circumvent failures between wires should 
be stated in the cable analysis. 


b. Component Failure Mode . Failures of major components consist- 
ing of one part require a listing of the modes in which that part 
may fail. Failures of major components consisting of more than 
one part will require a failure mode and effects reliability analy- 
sis to determine how the failure modes of each part will affect 
the components 1 output. These effects will be the failure modes of 
the major component listed in the Fault Hazard Analysis. All fail- 
ure modes of the component must be listed. 


c. Component Failure Rate . The predicted reliability or the failure 
rate computed from the best available data of primary failures 
should be tabulated in this column for each major component in 
each of its modes of failure. These data can be used in evaluating 
probability of the fault event or in selecting which critical or 
catastrophic events should be analyzed if the decision is made not 
to analyze all events so classified. These data also serve as a 
data bank for future reference when the need arises to analyze 
other undesired events as a result of system changes. 
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d. System Operational Mode. Many major components are only 
recurrently activated during the system's operational life. The 
level of stress of these components will change from one system 
mode to another. The effect of a failure in each mode can be dif- 
ferent; for example, components supplied with power only during 
a test can create a fault hazard only while a test is performed. 
Failures existing in one mode of system operations can also 
adversely affect the system when the mode is changed. Therefore, 
each major component failure mode must be analyzed for possible 
effects on all system operational modes. 

e. Effect of Primary Component Failure on Subsystem . The effect of 
the component's abnormal output on the operation is listed in this 
column. The effect will be of the immediate functional output on 
the most proximate downstream components. No secondary con- 
siderations are necessary. A description of the functional effect 
on normal subsystem operation will supply the required infor- 
mation. Some failures can initiate a normal chain of events within 
the subsystem. Those sequences that are inherent to the design 
can also be reported as a primary effect. The description of the 
subsystem effect should be identified by its particular oriented 
function and also by form and magnitude of output energy. This 
information is necessary when using the completed Fault Hazard 
Analysis for construction of the Logic Diagram Analysis. Once 
an undesired event has been defined, all primary failure modes 
can be found by scanning this column. 

f. Factors That May Cause Secondary Component Failure 

(1) Any major component operating in a system is subject to out- 
of-tolerance or abnormal inputs. There may be no source of 
such conditions within the subsystem under analysis, but once 
integrated into a system, abnormalities can arise. To insure 
detection of the hazardous secondary conditions which can 
cause equipment failure, the limits beyond which failure oc- 
curs will be listed. This information is very significant, be- 
cause a failure causing an out-of-tolerance condition can 
affect many critical system functions simultaneously and may 
degrade the system's safety. 

(2) The following information, where applicable, should be included 
in this column: 

(a) Effect of power reversals. 

(b) Effect of high and low power. 

(c) Temperature and moisture limits. 

(d) Shock limits, 

(e) Vibration limits. 

(f) RFI limits. 
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(g) Electromagnetic limits. 

(h) Transient effects. 

(i) Chemical effects (including corrosion). 

(j) Any other source of energy which, if supplied in sufficient 
quantity, will cause the primary failure rate to increase. 

g. Upstream Components or Inputs that May Cause Sequential 
Failures . The analysis cannot be continued unless it is known how 
the out-of- sequence event could occur due to the power functioning 
of the component. It was shown above that a fault effect on a sub- 
system may be caused by a primary or secondary failure on a 
component. This column shows how the fault effect on the sub- 
system may be caused by the component as the result of having 
improper input signals applied. This is termed a "sequential 
failure" and describes the specific subsystem oriented functions 
and their energy level required to cause the out-of- sequence 
failure mode. Improper outputs of the most proximate upstream 
components should be listed. 

h. Further Analysis Required . Having completed the analyses nec- 
essary to fill out the preceding columns, the analyst is prepared 
to make recommendations on the necessity for additional analyses 
or corrective action. The basis for these recommendations is the 
result of reviewing the data developed against the risk factors of 
severity , exposure and probability of occurrence as cited pre- 
viously, and a yes or no decision is reached which is entered in 
Column h with appropriate remarks added to Column i. 

i. Remarks 

(1) This column is used to include additional information needed 
to clarify or verify information in the other columns, or to 
provide a permanent note of recommended future action. A few 
examples of usage are given below: 

(a) Describe the number and type of monitors on this major 
component failure mode, if known. 

(b) Show the recommendations for further system analysis or 
corrective action as a permanent note. 

(c) Explanation of a major component definition in doubtful 
cases. 

(d) A coding to show data source and validity of the primary 
failure rates. 

(e) A discussion of sequential failure events is entered in 
Column g. 

(f) When applicable, a statement that the major component is 
an interface component and requires an input from another 
subsystem or can provide the abnormal output in Column e. 
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(2) When the decision is made not to proceed into the logic dia- 
gram analysis, the product of the Fault Hazard Analysis -- 
which is included in Columns g and h of the tabulation -- may 
be used as follows: 

(a) To provide visibility as to the relative safety at the sub- 
system level. 

(b) To establish the need for additional design requirements, 
safety devices, control procedures or mission constraints 
(red line values). 

(c) As background safety data for support of design reviews to 
assure that safety requirements have been met. 

(d) As the basis for safety support of trade-off studies. 

3205 LOGIC DIAGRAM ANALYSIS 

1. GENERAL 


The logic diagram analysis technique is the final progres sive step in 
the series of safety analyses. The effort can be undertaken in incre- 
ments as the major subsystem configurations are defined; however, 
the complete system configuration must be established before the 
total analysis can be accomplished. The analysis is flexible and pro- 
vides maximum visibility for the total system viewpoint by clearly 
showing the critical fault paths that exist in the system, which are not 
revealed by the previously described analytical techniques. 

2. METHOD 

A logic diagram is a graphic representation of the various parallel 
and series combinations of subsystem failures which can result in 
a predetermined system failure. The accomplishment of a Logic 
Diagram Analysis is undertaken in the following series of steps: 

a. Definition of the Undesired Event . Every system developed has 
one or more events which that system cannot tolerate, such as 
a catastrophic loss of a system, loss of a crew, or loss of a 
mission. It follows then that these are the events which must be 
prevented from occurring; and, in turn, prevention of these events 
becomes the objective of the logic diagram analysis. The initial 
step in the performance of a logic diagram analysis is the defi- 
nition of the event which must be kept from happening. While the 
definition of these undesired events may originate from within 
the functional safety organization, senior management concur rence 
should be obtained as a prerequisite to begin the analysis. 

b. Obtain Data That Describes the System and Its Planned Use : 

(1) Update the data obtained for the Fault Hazard Analysis to the 
current baseline. 

(2) Develop cognizance of all significant changes to the system 
baseline. 
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c. Develop the Logic Diagram . Once the predetermined event has 
been established as described in subparagraph a above, deter- 
mine the necessary parallel and series events which will cause 
the end event to occur. This process is continued through the sub- 
system level to the appropriate component or piece-part level. 
In cases of safety critical components, as defined in the Fault 
Hazard Analysis, the process is always continued to the piece- 
part level. These series and parallel events are connected by 
use of the following graphic symbols: 

(1) Events , The various kinds of events used in a logic diagram 
are represented by the following symbols: 


(a) The RECTANGLE identifies 
an event that results from a 
combination of fault events. 


(b) The CIRCLE identifies a ba- 
sic failure of a component. 


(c) The HOUSE indicates an event 
which is normal for the sys- 
tem. 


(d) The DIAMOND identifies a 
failure which has not been 
fully developed due to lack of 
information or significance. 


(2) Logic Operators . The logic op- 
erators required to develop the 
logic diagram are defined and 
symbolized as follows: 


(a) The AND GATE describes the 
logical operation which re- 
quires the coexistence of all 
inputs to cause the output. 


Output 

I 



Output 



o 


Output 



i r 

Inputs 
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(b) The PRIORITY AND GATE 
performs the same function 
as the AND GATE except that 
the inputs must occur in the 
sequence stipulated. 


Output 



Inputs 


(c) The CONSTANT REPAIR 
performs the same function 
as the AND GATE except that 
the repair time of the output 
event is not dependent on the 
repair times of the inputs. 



Inputs 


(d) The OR GATE describes the 
logical operation whereby the 
output is caused by the oc- 
currence of any of the inputs. 


(e) The EXCLUSIVE OR GATE 
performs the same function 
as the OR GATE except that 
specified inputs cannot co- 
exist. 


Output 



Inputs 


(f) The CONSTANT REPAIR OR 
GATE performs the same 
function as the OR GATE ex- 
cept that the repair time of 
the output event is not de- 
pendent on the repair times 
of the input. 


Output 



Inputs 
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(g) The INHIBIT GATE describes 
a situation in which a certain 
condition of the system must 
exist before one failure pro- 
duces another. The inhibit 
condition may be either nor- 
mal to the system or be the 
result of equipment failures. 


Output 



Output 



(h) The MATRIX GATE is used 
to describe a situation in 
which an output event is pro- 
duced for certain combina- 
tions of events at the inputs. 
A matrix showing the event 
combinations that produce the 
output event will accompany 
each usage of this symbol. 


Output 



Input 


(3) Special Symbols. Special sym- 
bols are used in order to sim- 
plify the graphic representa- 
tion of fault tree construction. 
These special symbols are shown 
below: 


(a) The TRANSFER symbol is 
used to show continuity be- 
tween two parts of the tree. 
A line into the side of the 

triangle transfers everything 
below to another area identi- 
fied by the triangle with a 
line drawn from the apex. 


Output 
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(b) An ELLIPSE with a line ex- 
tending out along the major 
axis is used when a compo- 
nent appears several times 
at the same place (e.g., at 
10 stage counter). Only one 
of the inputs is drawn and the 
ellipse is drawn to encompass 
the output. This indicates 
that the failure rate of that 
event is to be multiplied by 
the given factor for an OR 
GATE or raised to a given 
power for an AND GATE. 

d. Critical Fault Path Identification 

(1) A critical fault path is that chain of events which is the most 
likely to result in a particular predetermined event or poten- 
tial accident. There may be several chains of various degrees 
of dominance. These chains and their associated degrees of 
dominance are most clearly identified in the system safety 
model (logic diagram). Critical fault path(s) and their relative 
degree of dominance are determined either by event weighting 
(inspection) or mathematical solution of the model. 

(2) Since the most critical fault path is the most likely avenue 
along which predetermined event(s) can occur, the most effec- 
tive approach is to concentrate the initial corrective action in 
this area. It may be necessary to consider other paths within 
the model, in a descending order of dominance, in order to 
achieve an acceptable level of risk for the occurrence of a 
particular predetermined event or potential accident. 

(3) The steps required to provide effective use of the identification 
of critical fault paths are as follows: 

(a) Assure that the system safety model for a given predeter- 
mined event or potential accident has been developed to the 
extent necessary to identify critical fault paths. As a mini- 
mum the logic diagram development must encompass all 
these safety features and devices which have been designed 
into the system which may be extracted from the previous 
analyses. This assures that adequate consideration has 
been given to those areas of the system which contain the 
greatest risk. Safety features and devices are normally 
placed where there exists the greatest risk of an undesired 
event occurring. 

(b) By logical inspection or mathematical process, determine 
the degree of dominance for those critical fault paths of the 
model which contribute the most to the risk. Logical in- 
spection is the logical thought process of a trained and 
experienced analyst being applied through examination of 
the model. This process, associated with whatever mental 
weighting factors he may consider during the examination 


Output 
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to determine which events "look to be" more probable than 
others, would lead to the resulting statement by the ana- 
lyst: "these events (identified) and critical fault path(s) 
look to be the most probable." The term "mathematical 
process" can be a solution of the model by any of several 
methods. Since the purpose of the quantitative evaluation of 
a diagram is to evaluate the critical fault paths and estab- 
lish their relati ve significance , the diagram is usually sim- 
plified by inspection to minimize the logic diagram struc- 
ture to be evaluated. This inspection results in elimination 
of those events and branches which are obviously insig- 
nificant compared to others which are inputs to the same 
gate. 

(c) Evaluate the dominant critical fault paths by accomplishing 
the following steps: 

(i) Establish a predetermined limit within which the initial 
path selection is bounded. This involves the identifi- 
cation of those paths which are computed to be above 
any established limit for the system. If the paths are 
near or below the limit, then they are selected by pick- 
ing those which are within an "order of magnitude" or 
so of the limit, or are of the same type. 

(ii) The initial selection must be divided into groups for 
which a set of predetermined limits has been established 
for each grouping. The grouping of paths is accom- 
plished by selecting those within an order of magnitude 
of each other or those which have an apparent com- 
monality within the system. 

(iii) Determine whether a common point of departure exists 
among the paths of each group. This evaluation involves 
determining whether there are common faults among 
the paths. Recommended changes to the s ystem at these 
common points provide the most effective way to elimi- 
nate critical fault path s, or at least reduce them to 
an acceptable level of risk ^ 

(iv) Convert the logic diagram dominant critical fault paths 
by grouping events at logical summary points. Conver- 
sion of the logic diagram critical fault paths involves 
making a listing of those events which when "ored" 
result in an interim event. The method is to convert 
each path to a simplified alternating "and", "or", "and", 
"or", etc., relationship. 

(v) Simplify the logic diagram of the dominant critical fault 
path by logically re-diagramming. 

(vi) Determine those even ts for which a design change or the 
development of a procedure will best and most cost- 
effectively reduce the probability of occurrence of an 
undesired event to an acceptable level of risk. 
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(vii) System safety trade-off studies may be made by insert- 
ing alternative solutions as derived by subparagraphs ( 1 ) 
through (vi) and repeating the process until an accept- 
able level of risk is obtained. This step involves working 
with designers and selecting several alternative system 
changes to reduce the probability of occurrence of each 
path. For each alternative to be evaluated the logic 
diagram is changed to reflect the change and the dia- 
gram is re- computed to determine the change impact. 
Care must be exercised to assure that other paths or 
branches of the diagram which have the same event or 
fault sequence are also changed to reflect the change 
being evaluated, 

(viii) Advise appropriate level of management of findings and 
recommendations . 

(ix) Diagnostic analyses also may be performed by the use 
of this technique. The analyst sets the accident that ac- 
tually happened as his undesired event and develops the 
diagrams as described in subparagraphs a through c 
above. 


3206 PROCEDURES ANALYSIS 

1. GENERAL 

The purpose of the procedures analysis is to identify and/or imple- 
ment the safety requirements that should be met to assure safe test 
or operation of the system. The data required for the performance of 
these analyses include: 

a. Drawings, specifications and hardware (system) descriptions, 

b. Mission time lines or test requirements. 

c. Results of all safety analyses previously performed. 

d. Historical data from previously performed tests on similar 
systems . 

2. THE SAFETY- PROCEDURES INTERFACE 

The safety-procedures interface is established in three steps as 
follows: 

a. Working with the engineering organization, establish specific 
safety requirements and insert them into the test or operations 
requirements documentation. 

b. Review the test or operations procedures when they have been 
prepared to verify that the safety requirements included in the 
test or operations requirements documentation have been included 
in the procedures. Special attention should be devoted to backout 
and shutdown capability and to assure the procedures include 
end-to-end verification. 
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c. Monitor the actual test or operation to assure the adequacy of 
the safety impact to the procedures and to assure that the re- 
quirements are followed. 

Test procedures include developmental, qualification, acceptance and 
system validation. Operating procedure includes handling, storage, 
transportation, maintenance, operation and emergency. 

3. METHOD 

a. This analysis technique involves the review of all operating pro- 
cedures associated with the program. Emphasis is placed on the 
completeness of the procedures, including all cautions to be exer- 
cised regarding inadvertant out-of-sequence operations, and the 
inclusion in the procedures of adequate recycle and backout in- 
structions to counter potential emergency situations. Documenta- 
tion of identified hazards involved with operational and remedial 
procedures will provide management visibility of the risks in- 
volved and corrective action needed for avoiding or reducing the 
hazards. 

b. Analyses consisting of reviews of prepared procedures for the 
following nonoperational activities in a system development pro- 
gram should include: 

(1) Manufacturing 

(2) Personnel Skill Certification 

(3) Test 

(4) Transportation 

(5) Storage 

(6) Pre- Operation Checkout 

(7) Maintenance 

c. Figures 9 and 10 are typical checklists that contain hazard 
examples that may benefit the safety analyst in performing pro- 
cedures analyses. 

3207 REQUIREMENTS VERIFICATION 

1. The product of the analytical safety effort consists of safety visi- 
bility used in support of risk managenent decisions and safety re- 
quirements used to influence design or procedures that test or oper- 
ate the system. It is necessary not only to establish the initial safety 
requirements and criteria, but to evaluate these requirements and 
criteria on an iterative basis to assure they accomplish the intent 
for which they were originated. Moreover, new requirements may be 
developed or existing requirements changed in order to maintain the 
established safety level of the system. 
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Figure 9 


2-20 




2-21 



2. Original safety requirements and criteria stem from data extracted 
from experience gained on similar systems, standard system safety 
technology and the preliminary hazards analysis. More detailed 
safety analysis such as the fault hazard analysis and the logic dia- 
gram analysis will yield requirements that are unique to the evolving 
system. 

3. Concurrently with the performance of these analyses, the original 
safety criteria should be assessed to verify that these requirements 
correctly continue to influence the design as it evolves. It is essen- 
tial, as these safety requirements are developed or refined, that they 
be documented and that this documentation be maintained on an up- 
to-date basis for design use. 
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APPENDIX A: INSTALLATION SUPPLEMENTAL INSTRUCTIONS 
AND REQUIREMENTS 


1. In order that all regulations concerning various aspects of the NASA 
Safety Program (i.e., agency and installation) are maintained in one pub- 
lication, the volumes of the NASA Safety Manual have been designed so 
that installation supplements will be issued and filed with the basic regu- 
lations. 

2. Installations will issue, as Supplements to each volume, their implement- 
ing instructions in a format similar to that indicated in Exhibit A of this 
Appendix. The installation Supplements will be issued as page inserts to 
those paragraphs needing implementation and will be filed as near to the 
implemented paragraph as possible. The implementing instructions will be 
printed on color paper stock. 

3. The Cover Sheet for each Supplement will be in a format similar to that 
indicated in Exhibit B and will contain the following information: 

a. A list of the basic paragraphs being implemented, 

b. A synopsis, if helpful, of the new implementing instructions. 

c. A statement that basic paragraphs should be annotated "See 

Sup. " 

4. In the sample formats in Exhibits A and B, the abbreviation "NHQ" desig- 
nates "NASA Headquarters." Field installations should use individual 
designations (e.g., "MSC" for Manned Spacecraft Center, "FRC'for Flight 
Research Center). Headquarters Supplements will be printed on green 
paper. 

5. In no case will this volume be reproduced or reprinted in any manner. 
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NHQ SUPPLEMENT 1 
to 

NASA Safety Manual 
(NHB 1700. 1(V3) 

Issue Date: 

This Supplement contains NASA Headquarters (NHQ) 
implementation of basic paragraphs 1302, 3401 and 
3504, These paragraphs should be annotated M See NHQ 
Sup. l. M 

NHQ 3032 Requires processing of NHQ. Form 00 


through Code BN. 



FILING INSTRUCTIONS 


1. (Include appropriate instructions for filing.) 



EXHIBIT B-- COVER SHEET 
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APPENDIX B: SYSTEM SAFETY REFERENCES 


SAFETY PROGRAM 
DIRECTIVE NO. 1 

NASA TM-X 53282 

NASA TM-X 53612 

NASA TM-X 53305 

NASA TM-X 53 664 

NASA TM-X 53563 
NASA TM-X 53388 
NHB 5300. 4( 1A) 

SP 6506 

AFSC DH 1- 1 
AFSC DH 1-6 

AFSCM 127- 1 
AMCP 385-23 
MIL-STD 882 


NASA 

SYSTEM SAFETY REQUIREMENTS FOR MANNED 
SPACE FLIGHT, OMSF, WASHINGTON, D.C. 

LAUNCH VEHICLE SAFETY ENGINEERING FOR 
STANDARD PAYLOAD MODULE, OCTOBER 20, 1965, 
MSFC 

THE SYSTEMS SAFETY PROGRAM FOR A TOTAL 
SPACE LAUNCH VEHICLE GENERAL REQUIRE- 
MENTS, MAY 23, 1967, MSFC 

STANDARD PAYLOAD MODULE SYSTEM ANALYSIS 
PROCEDURES FOR SYSTEM DEFINITION, JULY 26, 
1965, MSFC 

SYSTEMS SAFETY CRITERIA FOR USE IN PREPA- 
RATION OR REVIEW OF PROCEDURES, OCTO- 
BER 17, 1967, MSFC 

SYSTEM SAFETY HANDBOOK, JANUARY 6, 1967, 
MSFC 

SATURN V SYSTEM SAFETY PROGRAM ADEQUACY 
EVALUATION, FEBRUARY 1, 1966, MSFC 

RELIABILITY PROGRAM PROVISIONS FOR SPACE 
SYSTEM CONTRACTORS, R&QA, CODE KR, WASH- 
INGTON, D.C. 

AN INTRODUCTION TO THE ASSURANC E OF HUMAN 
PERFORMANCE IN SPACE SYSTEMS, R&QA, CODE 
KR, WASHINGTON, D.C. 


POD 

DESIGN HANDBOOK 

DESIGN HANDBOOK, "SYSTEM SAFETY" (Also ref- 
erence listed herein.) 

SYSTEM SAFETY MANAGEMENT 

MANAGEMENT SYSTEM SAFETY 

SYSTEM SAFETY PROGRAM FOR SYSTEMS, AND 
ASSOCIATED SUBSYSTEMS AND EQUIPMENT: Gen- 
eral Requirements for 
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AFETRM 127- 1 
AFSCM 127-1 

SAMSOM 127- 1 
EXHIBIT 68-8 
SAMSO 

D2- 117018- 1 
D2-84303- 1 

D2- 119062-1 


RANGE SAFETY MANUAL (VOLUME 1) 

SAFETY, SYSTEM SAFETY MANAGEMENT, AIR 
FORCE SYSTEMS COMMAND 

SAFETY, PLANS, PROGRAMS AND PROCEDURES 
(Volume IV), SYSTEM SAFETY ENGINEERING, SPACE 
AND SYSTEMS ORGANIZATION MANUAL, USAF 

WEAPONS SYSTEMS SAFETY ANALYSIS REQUIRE- 
MENTS, SAMSO- AFSC, LOS ANGELES, CALIFORNIA, 
NOVEMBER 1968 

SYSTEM SAFETY ENGINEERING, HAZARD ANALYSIS 
REQUIREMENTS, SAFETY OFFICE (SMW) SAMSO- 
AFSC, LOS ANGELES, CALIFORNIA, JULY 1968 
(MAJOR P. J. STACK) 


CONTRACTOR 

APOLLO LOGIC DIAGRAM ANALYSIS GUIDELINES, 
THE BOEING COMPANY, SEATTLE, JUNE 1968 

SYSTEMS SAFETY ENGINEERING ANALYSES TECH- 
NIQUES, THE BOEING COMPANY, SEATTLE, FEB- 
RUARY 1963 

SYSTEM SAFETY ENGINEERING ANALYSIS HAND- 
BOOK, THE BOEING COMPANY, COCOA BEACH, 
FLORIDA, JUNE 1969 
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APPENDIX C: TRAINING COURSES 


COURSE NO. 

TITLE 

SCHOOL 

DURATION 

104 

System Safety 

George Washington Univ. 
Washington, D.C. 

2 weeks 

- 

System Safety Analysis 

University of Washington 
Seattle, Washington 

2 weeks 

ASM 576 

Fundamentals of 
System Safety 

University of Southern 
California, Los Angeles 

3 weeks 

ASM 577 

Aeronautical Systems 
Safety 

University of Southern 
California, Los Angeles 

3 weeks 

ASM 578 

Missile and Space 
Vehicle Systems Safety 

University of Southern 
California, Los Angeles 

3 weeks 

ASM 579 

System Safety 
Technology 

University of Southern 
California, Los Angeles 

3 weeks 


Advanced Safety 
Program Management 

University of Southern 
California, Los Angeles 

3 weeks 








